The workflow built server/ in the runner's own workspace and restarted
crate-api, but nothing ever put that build where the unit actually runs
it. crate-api.service has WorkingDirectory=~/T19-Project-2/server and
ExecStart=.../node dist/index.js, so a restart just brought back whatever
had been installed on the machine by hand. Reported by rachelks on #42.

The deploy step now:

1. checks out $GITHUB_SHA in ~/T19-Project-2, which is a git clone of
   main as of this issue rather than a hand copy
2. installs and builds server/ there
3. restarts crate-api and polls until /graphql answers
4. runs a smoke suite through the same Apache proxy the browser uses

Three things this fixes that were wrong before:

- The unit check is [ -f ... ], not `systemctl list-unit-files | grep`.
  grep -q closes the pipe at the first match, systemctl dies of SIGPIPE,
  and with pipefail the pipeline reports failure. The if took the else
  branch and skipped a service that was definitely there.

- The restart needs a NOPASSWD sudoers rule, because the runner has no
  TTY. Scoped to three systemctl commands.

- No sleep. Type=simple reports active before Node binds the port, and a
  measured 1850 ms startup made `sleep 2` produce a 503 through Apache.
  It polls instead.

Verified on the VM: ~/T19-Project-2 is a real clone at 0fbd54a, git fetch
works with the deploy key added for that machine, `checkout --force` leaves
.gitignore's .env untouched (it holds DATABASE_URL), and sudo is
passwordless for the three commands.

The skip guard for `server/` stays, because #42 has not merged yet. Once
it does, the next push to main will deploy the API end to end.

Co-Authored-By: opencode <noreply@opencode.ai>

The workflow built server/ in the runner's own workspace and restarted
crate-api, but nothing ever put that build where the unit actually runs
it. crate-api.service has WorkingDirectory=~/T19-Project-2/server and
ExecStart=.../node dist/index.js, so a restart just brought back whatever
had been installed on the machine by hand. Reported by rachelks on #42.

The deploy step now:

1. checks out $GITHUB_SHA in ~/T19-Project-2, which is a git clone of
   main as of this issue rather than a hand copy
2. installs and builds server/ there
3. restarts crate-api and polls until /graphql answers
4. runs a smoke suite through the same Apache proxy the browser uses

Three things this fixes that were wrong before:

- The unit check is [ -f ... ], not `systemctl list-unit-files | grep`.
  grep -q closes the pipe at the first match, systemctl dies of SIGPIPE,
  and with pipefail the pipeline reports failure. The if took the else
  branch and skipped a service that was definitely there.

- The restart needs a NOPASSWD sudoers rule, because the runner has no
  TTY. Scoped to three systemctl commands.

- No sleep. Type=simple reports active before Node binds the port, and a
  measured 1850 ms startup made `sleep 2` produce a 503 through Apache.
  It polls instead.

Verified on the VM: ~/T19-Project-2 is a real clone at 0fbd54a, git fetch
works with the deploy key added for that machine, `checkout --force` leaves
.gitignore's .env untouched (it holds DATABASE_URL), and sudo is
passwordless for the three commands.

The skip guard for `server/` stays, because #42 has not merged yet. Once
it does, the next push to main will deploy the API end to end.

Co-Authored-By: opencode <noreply@opencode.ai>

The workflow built server/ in the runner's own workspace and restarted
crate-api, but nothing ever put that build where the unit actually runs
it. crate-api.service has WorkingDirectory=~/T19-Project-2/server and
ExecStart=.../node dist/index.js, so a restart just brought back whatever
had been installed on the machine by hand. Reported by rachelks on #42.

The deploy step now:

1. checks out $GITHUB_SHA in ~/T19-Project-2, which is a git clone of
   main as of this issue rather than a hand copy
2. installs and builds server/ there
3. restarts crate-api and polls until /graphql answers
4. runs a smoke suite through the same Apache proxy the browser uses

Three things this fixes that were wrong before:

- The unit check is [ -f ... ], not `systemctl list-unit-files | grep`.
  grep -q closes the pipe at the first match, systemctl dies of SIGPIPE,
  and with pipefail the pipeline reports failure. The if took the else
  branch and skipped a service that was definitely there.

- The restart needs a NOPASSWD sudoers rule, because the runner has no
  TTY. Scoped to three systemctl commands.

- No sleep. Type=simple reports active before Node binds the port, and a
  measured 1850 ms startup made `sleep 2` produce a 503 through Apache.
  It polls instead.

Verified on the VM: ~/T19-Project-2 is a real clone at 0fbd54a, git fetch
works with the deploy key added for that machine, `checkout --force` leaves
.gitignore's .env untouched (it holds DATABASE_URL), and sudo is
passwordless for the three commands.

The skip guard for `server/` stays, because #42 has not merged yet. Once
it does, the next push to main will deploy the API end to end.

Co-Authored-By: opencode <noreply@opencode.ai>

…checks

Four points from rachelks on #45.

1. The searchAlbums smoke query omitted `sort`, which is `AlbumSort!` in
   AlbumSearchInput, so the query failed validation and the check could
   never pass. Now sends `sort: TITLE_ASC`.

2. The skip guards for crate-api.service and server/ now fail instead of
   exiting 0. #42 has merged so both are expected, and a deploy job that
   goes green without deploying anything is the wrong failure mode.

3. The body check parses the JSON rather than grepping for the word
   "errors". Grep would also fire on an album called "Errors", and it did
   not verify `data` was present at all. Now rejects a response with
   errors, with no data, or that is not JSON. Added a totalCount
   assertion as well, so the check is on the data and not only on its
   presence.

4. The python validators live in shell variables on one line. A
   multi-line `python3 -c` heredoc cannot be used inside a YAML block
   scalar: the block ends at the first unindented line and the workflow
   stops parsing. Learned by breaking it.

Also rebased onto main now that #42 and #43 have merged.

Validated the two python expressions against five payloads: a good
response, GraphQL errors, null data, a valid totalCount, and two bad
ones. Each rejected case prints what was wrong.

Co-Authored-By: opencode <noreply@opencode.ai>

The workflow built server/ in the runner's own workspace and restarted
crate-api, but nothing ever put that build where the unit actually runs
it. crate-api.service has WorkingDirectory=~/T19-Project-2/server and
ExecStart=.../node dist/index.js, so a restart just brought back whatever
had been installed on the machine by hand. Reported by rachelks on #42.

The deploy step now:

1. checks out $GITHUB_SHA in ~/T19-Project-2, which is a git clone of
   main as of this issue rather than a hand copy
2. installs and builds server/ there
3. restarts crate-api and polls until /graphql answers
4. runs a smoke suite through the same Apache proxy the browser uses

Three things this fixes that were wrong before:

- The unit check is [ -f ... ], not `systemctl list-unit-files | grep`.
  grep -q closes the pipe at the first match, systemctl dies of SIGPIPE,
  and with pipefail the pipeline reports failure. The if took the else
  branch and skipped a service that was definitely there.

- The restart needs a NOPASSWD sudoers rule, because the runner has no
  TTY. Scoped to three systemctl commands.

- No sleep. Type=simple reports active before Node binds the port, and a
  measured 1850 ms startup made `sleep 2` produce a 503 through Apache.
  It polls instead.

Verified on the VM: ~/T19-Project-2 is a real clone at 0fbd54a, git fetch
works with the deploy key added for that machine, `checkout --force` leaves
.gitignore's .env untouched (it holds DATABASE_URL), and sudo is
passwordless for the three commands.

The skip guard for `server/` stays, because #42 has not merged yet. Once
it does, the next push to main will deploy the API end to end.

Co-Authored-By: opencode <noreply@opencode.ai>

…checks

Four points from rachelks on #45.

1. The searchAlbums smoke query omitted `sort`, which is `AlbumSort!` in
   AlbumSearchInput, so the query failed validation and the check could
   never pass. Now sends `sort: TITLE_ASC`.

2. The skip guards for crate-api.service and server/ now fail instead of
   exiting 0. #42 has merged so both are expected, and a deploy job that
   goes green without deploying anything is the wrong failure mode.

3. The body check parses the JSON rather than grepping for the word
   "errors". Grep would also fire on an album called "Errors", and it did
   not verify `data` was present at all. Now rejects a response with
   errors, with no data, or that is not JSON. Added a totalCount
   assertion as well, so the check is on the data and not only on its
   presence.

4. The python validators live in shell variables on one line. A
   multi-line `python3 -c` heredoc cannot be used inside a YAML block
   scalar: the block ends at the first unindented line and the workflow
   stops parsing. Learned by breaking it.

Also rebased onto main now that #42 and #43 have merged.

Validated the two python expressions against five payloads: a good
response, GraphQL errors, null data, a valid totalCount, and two bad
ones. Each rejected case prints what was wrong.

Co-Authored-By: opencode <noreply@opencode.ai>